This invention relates to network management tools for managing distributed networks and, in particular, to alarm management and alarm servicing tools.
Present day telecommunications and information networks have become larger and far more complex than those which have been available only a few years ago. The trend towards increases in size and complexity can be expected to continue at a high rate into the foreseeable future with the proliferation of cellular networks, the development and deployment of global satellite networks, and the expansion of basic wireline networks in developing nations. Both homogeneous and heterogeneous networks are now being connected together by means of the Internet and other inter-network connection mechanisms.
In order to maintain network reliability and an acceptable quality of service, it is necessary to carefully monitor and manage network resources. However, as existing networks grow larger and more complex, network management also becomes more difficult and more complex. The prior art responded by providing automated management tools for reporting network status. These tools allowed network management personnel to improve the quality of service and maintain high network availability and reliability.
Such automated management tools were distributed and generally arranged as client server applications which provided integrated for supporting heterogeneous network environments. The client portion of the tools was arranged to have a standard interface which minimized variations of look and feel of the system as seen by the network operations personnel whereas the server portion was designed to operate on different platforms. The distributed architecture allowed the tool to evolve and scale as the networks evolved in size, capabilities, and geographies.
One such distributed network management tool is the Solstice Enterprise Manager(trademark) (Solstice EM) network management system which was developed and is marketed by Sun Microsystems, Inc. This tool has an object-oriented and distributed architecture which consists of a plurality of cooperating components, including applications, libraries, information services, databases, and protocols, each of which performs specific tasks. The managed resources are arranged as a plurality of interconnected nodes and xe2x80x9cmanagement agentsxe2x80x9d running in each node gather information about the resources associated with the node. The information is then forwarded back to a management information server (MIS) which interacts with management applications running in other nodes. The MIS can request and change management parameter values, perform requested actions, and receive and evaluate problem reports (e.g. events, such as SNMP traps and CMIP notifications) that the management agents generate.
Although the MIS and the management agents can communicate with each other via various network management protocols such as Simple Network Management Protocol(SNMP), Common Management Information Protocol (CMIP), or other proprietary/legacy protocols, the Solstice EM(trademark) framework interposes software model representations of managed resources in the MIS between management applications and agents of managed resources. The result is that the management applications need not be concerned with management protocol dependencies of the managed resources since the applications only interact with the software model representations in the MIS.
In particular, the management applications direct management tasks in the MIS via a xe2x80x9cPortable Management Interface (PMI)xe2x80x9d which is a high-level abstraction of an interface for manipulating objects, regardless of their class description, supported protocol, or location. The PMI is also used by the MIS to communicate with the management agents. For example, the MIS can use a management protocol adapter (MPA) to communicate with a management agent. An MPA translates MIS requests to protocol-specific primitives (e.g. CMIP, SNMP, RPC, or other proprietary/legacy protocol primitives) depending upon the management agent in question. For example, a CMIP MPA communicates with CMIP agents.
One of the most important tasks that a network manager can perform is xe2x80x9calarmxe2x80x9d monitoring and management. An alarm is an unsolicited notification called a xe2x80x9ctrapxe2x80x9d in SNMP terminology and an xe2x80x9ceventxe2x80x9d in CMIP terminology which is generated by an agent and sent to the MIS. The notification generally indicates that a particular managed resource associated with the agent has experienced a fault or failure condition or otherwise requires attention. Alarms have an associated severity level which can range from xe2x80x9ccriticalxe2x80x9d to xe2x80x9cwarning.xe2x80x9d Network management personnel can manage the alarms by changing their state. For example, a newly generated alarm has an xe2x80x9copenxe2x80x9d state. Network management personnel can xe2x80x9cacknowledgexe2x80x9d the alarm indicating that the alarm has been noted. After investigating the problem, the alarm can be xe2x80x9cclearedxe2x80x9d, indicating the problem has been corrected.
Alarm Services is a module in the Solstice EM(trademark) MIS responsible for updating and storing the state of managed objects in the MIS. Alarms arrive at the MIS as event notifications (via an MPA, for example). When such an event is received by the MIS, it is stored in an alarm log as an alarm log record by a Logging Services module and the Alarm Services module is informed about the arrival of this alarm. The Alarm Services module maps each managed-object-based alarm to a corresponding node in a topology database (discussed below) and updates the alarm counters for that topology node based on the alarm severity. The Alarm Services module also keeps the severity synchronized so that it represents the highest (most critical) uncleared alarm log record that is posted against the topology node. The node status is propagated to applications like the Solstice EM(trademark) Viewer and displayed in the appropriate color. The alarm information is also sent to the Solstice EM(trademark) Alarm Manager application for display.
The Alarm Manager program is intended to be used by network administrators and operators, to allow them to quickly see problems in the enterprise, and give them access to enough information so the problem can be fixed. The Alarm Manager does not display the alarm notifications directly. Instead it displays the alarm log records in the alarm log database in a tabular format. Therefore, the Alarm Manager has filters which can discard unwanted alarm information and can summarize, sort, and prioritize alarm information in order to display the information in a manner which is most information to the network management personnel. The Alarm manager also monitors the alarm log for events such as object creation, object deletion and object attribute values changes so that its display can be updated in an appropriate manner. Further, the Alarm manager can change the state of an alarm. For example, network personnel can use the Alarm Manager to change the state of an alarm from xe2x80x9copenxe2x80x9d to xe2x80x9cacknowledgedxe2x80x9d or xe2x80x9ccleared.xe2x80x9d This can be accomplished by selecting a particular alarm on a display screen and invoking an option to change the alarm state.
The Alarm Manager typically displays log records as rows in a record table. When the alarm log has many records, the large number of rows will not fit on the screen. Consequently, a scroll bar is provided to allow a user to scroll the records up and down on the screen so that a desired record can be brought into view. When new records are added to the display, the scroll bar typically flickers and resizes to alter the user that new records have arrived.
However, there are problems with this arrangement. In particular, the flickering and resizing of the scroll bar is not sufficiently noticeable to signal network management personnel that new events have arrived. Even if an operator is viewing the display when new events arrive, it is very easy to miss the resizing and thus miss very critical events.
In addition, if an operator actually wants to see all of the incoming events as they arrive, the operator must continually click on the scroll bar as events come in. In a busy system, it is impossible to click fast enough to see all events. Further, it is difficult to accurately move the scroll bar. An operator can click on the scroll bar arrow button to scroll the events, but the arrow only scrolls down the display one event at a time and thus is slow. It would be more advantageous to click on the slider between the scroll bar thumb and the arrow, but if the log is large enough, this area is so small that it is nearly impossible to keep clicking in it accurately.
Consequently, some versions of the Solstice EM(trademark) system used an alarm manager in which incoming alarms caused the display to scroll automatically. However, in such systems there was no way of controlling the scrolling since it was inherent in the list control which displayed the alarm records Further, in such systems, scrolling always occurred in the xe2x80x9cupxe2x80x9d direction. However, depending on sort order, alarms could appear at either the top or bottom of the control. If alarms appeared at the bottom of the table a user would not be able to see them unless he manually scrolled the table down. In addition, in large systems, the constant movement of the display screen made it difficult to acknowledge individual alarms.
The aforementioned drawbacks are addressed in one illustrative embodiment of the invention in which the alarm manager display is arranged to have two modes of operation. In one mode of operation, the alarm manager display automatically scrolls when new events arrive. If there are sorting criteria defined, the alarm manager window scrolls either up or down depending on the sort order so that when new events arrive, they always appear on the screen. In the second mode of operation, the alarm manager window does not scroll when new events arrive.
In accordance with one embodiment of the invention, the scroll bar operational modes are selectable by an operator from a menu. In accordance with another embodiment, a special attribute name is added to the alarm manager configuration file. This attribute is read when the alarm manager is started and places the alarm manager into the operational mode in which it was last used.